home *** CD-ROM | disk | FTP | other *** search
- Subject: comp.mail.mime frequently asked questions list (FAQ) (3/3)
- Newsgroups: comp.mail.mime,comp.answers,news.answers
- From: mime-faq@ics.uci.edu (MIME FAQ maintainer)
- Date: Sat, 19 Nov 1994 11:12:50 GMT
-
-
- Archive-Name: mail/mime-faq/part3
- Version: $Id: mime3,v 3.10 1994/11/19 11:10:23 jsweet Rel $
- Posting-Frequency: monthly
-
-
- --
- ==========================================================
- comp.mail.mime frequently asked questions list (FAQ) (3/3)
- ==========================================================
- Part 3: Advanced Topics
- ~~~~~~
- --
-
- Overview
- --------
- This is part 3 of a Frequently Asked Questions document about MIME,
- the multipurpose and multi-media standard for Internet mail.
-
- Part 1 covers frequently asked questions.
-
- Part 2 is a listing of MIME products.
-
- Part 3 covers advanced topics.
- --
-
- 10) Information
- ---------------
-
- 10.1) MIME-relevant RFCs and other standards
-
- The RFCs mentioned here are mainly relevant to persons building MIME
- software. As an end user, if your mail system is nice to you, you
- won't really have to know very much about these things.
-
- RFC and Internet-Drafts are available by anonymous FTP from any decent
- archive site. If you're really stuck, try these URLs:
-
- ftp://ds.internic.net/rfc/
- ftp://ds.internic.net/internet-drafts/
-
- Additionally, RFCs may be requested from a mail-based archive server
- by sending a message to "mailserv@ds.internic.net". In the body of
- the message, include one of the following commands:
-
- document-by-name rfcNNNN
- document-by-name rfcNNNN.ps
- document-by-name rfc-index
-
- where NNNN is the number of an RFC to retrieve. Not all RFCs are
- available in PostScript (.ps) format. Retrieve the rfc-index to
- find out what's available.
-
-
- MIME is defined in RFC 1521 (MIME Mechanisms for Specifying and
- Describing the Format of Internet Message Bodies) and RFC 1522
- (Representation of Non-ASCII Text in Internet Message Headers).
-
- These are Internet standards-track protocols. For the full
- implications of this, see RFC 1610 (Internet Official Protocol
- Standards). Here is their current status.
-
- RFC 1521: Draft Elective Standard
- RFC 1522: Draft Elective Standard
-
- These two RFCs do not fully define MIME. For one thing, they are
- based on RFC 822 (Standard for the format of ARPA Internet text
- messages), as revised by RFC 1123 (Requirements for Internet hosts -
- application and support) and must be read in conjunction with these.
-
- For another, they are extensible. See 10.2 for a complete list of
- registered subtypes.
-
- There are a whole lot of other RFCs that deal with e-mail, including
- these.
-
- IAB standards or standards-track RFCs
-
- RFC 1700 Assigned Numbers [[ Way more than the title implies. ]]
- RFC 1653 SMTP Service Extension for Message Size Declaration
- RFC 1652 SMTP Service Extension for 8bit-MIMEtransport
- RFC 1651 SMTP Service Extensions
- RFC 1502 X.400 Use of Extended Character Sets
- RFC 1496 Rules for Downgrading Messages from X.400(88) to X.400(84)
- when MIME Content-Types are Present in the Messages
- RFC 1495 Mapping between X.400 and RFC-822 Message Bodies
- RFC 1494 Equivalences between 1988 X.400 and RFC-922 Message Bodies
- RFC 1424 Privacy Enhancement for Internet Electronic Mail: Part IV
- RFC 1423 Privacy Enhancement for Internet Electronic Mail: Part III
- RFC 1422 Privacy Enhancement for Internet Electronic Mail: Part II
- RFC 1421 Privacy Enhancement for Internet Electronic Mail: Part I
- RFC 1327 Mapping between X.400(1988)/ISO 10021 and RFC 822
- RFC 1314 File format for the exchange of images in the Internet
-
- Other RFCs (Informational, Experimental, or Historical)
-
- RFC 1641 Using Unicode with MIME
- RFC 1590 Media Type Registration Procedure
- RFC 1563 The text/enriched MIME Content-type
- RFC 1556 Handling of Bi-directional Texts in MIME
- RFC 1489 Registration of a Cyrillic Character Set
- RFC 1468 Japanese Character Encoding for Internet Messages
- RFC 1456 Conventions for Encoding the Vietnamese Language
- RFC 1428 Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
- RFC 1357 Format for emailing bibliographic records
- RFC 1345 Character Mnemonics & Character Sets
- RFC 1344 Implications of MIME for Internet mail gateways
- RFC 1343 User agent configuration mechanism for multimedia mail format
- information
- RFC 1339 Remote mail checking protocol
- RFC 1321 MD5 Message-Digest algorithm
- RFC 1225 Post Office Protocol: Version 3
- RFC 1211 Problems with the maintenance of large mailing lists
- RFC 1176 Interactive Mail Access Protocol: Version 2
- RFC 1197 Using ODA for translating multimedia information
- RFC 1154 Encoding header field for internet messages
- RFC 1153 Digest message format
- RFC 1049 Content-type header field for Internet messages
- RFC 1036 Standard for interchange of USENET messages
- RFC 934 Proposed standard for message encapsulation
- RFC 807 Multimedia mail meeting notes
-
- --------------------------------
-
- 10.2) MIME types
-
- There are registered and unregistered MIME types. Unregistered MIME
- types begin with an "x-" and their meanings generally depend on
- private agreements between senders and receivers. This section lists
- registered types and some known unregistered types.
-
- --------------------------------
-
- 10.2.1) List of registered MIME types
-
- The latest list of registered MIME types is available from this file:
-
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types
-
- The media-types file also lists character sets registered for use with
- MIME, access types for external-body contents, content-transfer-encodings,
- and MIME/X.400 mapping tables.
-
- A list of URLs follows for documents relevant to various media types.
- The media types are taken from the October, 1994 version of the
- aforementioned media-types file, but the URLs below aren't necessarily
- representative of the latest list of registered types. In general,
- each <type> has a directory whose name has this form:
-
- media-types/<type>/<subtype>
-
- The <type> directory contains the definitions of the subtypes of the
- given <type>/<subtype>.
-
-
- Application types:
-
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/activemessage
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/andrew-inset
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/applefile
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/atomicmail
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/dec-dx
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/dca-rft
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/mac-binhex40
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/macwriteii
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/msword
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/news-message-id
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/news-transmission
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/octet-stream
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/oda
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/pdf
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/postscript
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/remote-printing
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/rtf
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/slate
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/wita
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/wordperfect5.1
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/application/zip
-
- Audio types:
-
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/audio/basic
-
- Image types:
-
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/jpeg
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/gif
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/ief
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/image/tiff
-
- Message types:
-
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/external-body
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/partial
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/rfc822
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/message/news
-
- Multipart types:
-
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/alternative
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/appledouble
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/digest
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/header-set
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/mixed
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/multipart/parallel
-
- Text types:
-
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/plain
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/richtext
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/text/tab-separated-values
-
- Video types:
-
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/video/mpeg
- ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/video/quicktime
-
-
- Character sets:
-
- ISO-8859-1 see ISO_8859-1:1987
- ISO-8859-2 see ISO_8859-2:1987
- ISO-8859-3 see ISO_8859-3:1988
- ISO-8859-4 see ISO_8859-4:1988
- ISO-8859-5 see ISO_8859-5:1988
- ISO-8859-6 see ISO_8859-6:1987
- ISO-8859-7 see ISO_8859-7:1987
- ISO-8859-8 see ISO_8859-8:1988
- ISO-8859-9 see ISO_8859-9:1989
- US-ASCII see ANSI_X3.4-1968
-
- Access types for external contents:
-
- AFS CMU Andrew File System (Transarc Corp., Pittsburgh, PA, USA)
- ANON-FTP anonymous FTP (RFC 1635, RFC 959)
- FTP non-anonymous FTP (RFC 959)
- LOCAL-FILE directly retrievable file
- MAIL-SERVER request to a mail-based archive server
- TFTP trivial file transfer protocol (RFC 1350)
-
- Content transfer encodings:
-
- 7BIT BINARY
- 8BIT QUOTED-PRINTABLE
- BASE64
-
- --------------------------------
-
- 10.2.2) List of known unregistered MIME types
-
- Here is a list of some known x-types, x-subtypes, and x-parameters.
-
- The enumeration of these x-types here does not imply any kind of
- standardization or open specification. The meanings of x-types depend
- on private agreements between senders and receivers. Some x-types may
- eventually become registered types; see sections 10.2.1 and 11.1.
-
- Just because an x-type is generated by a proprietary mail user agent
- doesn't necessarily mean that only that MUA can handle the x-type.
- Metamail and MH, for example, permit you to set up your own mechanisms
- to handle various standard and non-standard content types. In
- particular, it may simply be a matter of invoking some commercial
- application (aka invoking an "external viewer") to view data used by
- that application. For example, FrameMaker or FrameViewer might be run
- to handle a content type of application/x-framemaker. (In the case of
- Frame documents, there are several ways to handle this---see Frame
- Technical Note 1359 or consult the comp.text.frame FAQ.) The Metamail
- source distribution comes with pre-defined mailcap entries for
- handling some x-types; these may offer clues about how to configure
- your own mail user agent.
-
- Not all of the x-types listed here begin with "x-". Although such
- non-standard types may contravene the MIME specification, the fact
- remains that someone out there is generating them. Listing such types
- here is not intended to enshrine such types.
-
- { NOTE: some of the meanings of these x-types are GUESSES by the FAQ
- maintainer. Please let us know about incorrect guesses, and, if
- possible, supply a URL pointing to information about the x-type.
-
- And please feel free to let us know about whatever wacko or not-so-wacko
- x-types that your UAs may unleash on an unsuspecting world. If you
- have a URL for a document that describes the format, so much the
- better. Please at least let us know what applications are generating
- the x-types in question. }
-
-
- Application types:
-
- application/x-aiff Z-Mail: AIFF audio data
- application/x-bcpio MHonArc: bcpio data
- application/x-bitmap Z-Mail: X11 bitmaps
- application/x-cpio MHonArc: cpio archives
- application/x-csh MHonArc: csh scripts
- application/x-dvi MHonArc: TeX DVI data
- application/x-framemaker Z-Mail: FrameMaker documents
- application/x-gtar MHonArc: GNU tar archives
- application/x-hdf MHonArc: hdf data
- application/x-inventor Z-Mail: for Inventor files
- application/x-island-draw Z-Mail: IslandDraw files
- application/x-island-paint Z-Mail: IslandPaint files
- application/x-island-write Z-Mail: IslandWrite files
- application/x-jot Z-Mail: Jot documents
- application/x-latex MHonArc: LaTeX documents
- application/x-macbinhex40 TCP/Connect II: Mac BinHex 4.0
- application/x-metamail-patch metamail: patches to metamail
- application/x-mif MHonArc: Frame MIF documents
- application/x-movie Z-Mail: MoviePlayer documents
- application/x-ms-tnef Worldtalk: proprietary "tunneling" type for MS Exchange
- application/x-netcdf MHonArc: netcdf data
- application/x-sgi Z-Mail: SGI ImageWorks documents
- application/x-sh MHonArc: sh scripts
- application/x-shar MHonArc: shell archives
- application/x-showcase Z-Mail: Showcase documents
- application/x-sv4cpio MHonArc: SVR4 cpio archives
- application/x-sv4crc MHonArc: SVR4 crc data
- application/x-tar MHonArc: tar archives
- application/x-tcl MHonArc: tcl programs
- application/x-tex MHonArc: TeX documents
- application/x-texinfo MHonArc: GNU texinfo documents
- application/x-troff MHonArc: plain troff documents
- application/x-troff-man MHonArc: troff -man documents
- application/x-troff-me MHonArc: troff -me documents
- application/x-troff-ms MHonArc: troff -ms documents
- application/x-ustar MHonArc: ustar data
- application/x-wais-source MHonArc: WAIS sources
- application/x-wingz Z-Mail: Wingz documents
- application/x-xpm1 Z-Mail: OL pixmap files
- application/x-wt-stf Worldtalk: proprietary "tunneling" type for Worldtalk
- application/x-zm-fax Z-Mail: Z-Fax documents
-
-
- Audio types:
-
- audio/x-aiff MHonArc: AIFF audio data
- audio/x-wav MHonArc: WAV audio data
- audio/x-macaudio Iride: NOT sampled Macintosh audio
-
- audio/x-next MH 6.8: self-describing audio data
- see ftp://ftp.ics.uci.edu/mh/contrib/multimedia/mhn-tutorial.ps
-
-
- Image types:
-
- image/g3fax X.400 mapping to/from g3-facsimile [RFC 1494]
- image/x-cmu-raster MHonArc: CMU raster data
- image/x-macpict TCP/Connect II, Iride: Macintosh PICT
- image/x-pbm MHonArc: portable bit map data
- image/x-pgm MHonArc: PGM data
- image/x-pict MHonArc: Mactinosh PICT data
- image/x-pnm MHonArc
- image/x-portable-anymap MHonArc
- image/x-portable-bitmap MHonArc
- image/x-portable-graymap MHonArc
- image/x-portable-pixmap MHonArc
- image/x-ppm MHonArc
- image/x-rgb MHonArc
- image/x-xbitmap MHonArc: in-lines into the HTML
- image/x-xbm MHonArc: in-lines into the HTML
- image/x-xpixmap MHonArc
- image/x-xpm MHonArc
- image/x-xwd MHonArc
- image/x-xwindowdump MHonArc: X window dump
-
-
- Text types:
-
- text/html MHonArc: WWW HTML
- text/unknown Worldtalk
- text/x-html MHonArc: WWW HTML
- text/x-setext MHonArc: setext
- text/x-usenet-faq Ohio State WWW FAQ document format
-
-
- Video types:
-
- video/x-msvideo MHonArc: Microsoft video data
- video/x-sgi-movie MHonArc: SGI movie data
-
-
- Other types:
-
- x-be2 old Andrew format
- x-sun-attachment Sun MicroSystems mailtool
- x-zm-multipart old Z-Mail format
-
-
- Content transfer encodings:
-
- uuencode uuencoded data
- x-uue uuencoded data
- x-uuencode uuencoded data
-
-
- Character sets:
-
- charset=x-unknown MH 6.8.3: for untagged charsets
-
-
- Miscellaneous parameters:
-
- x-conversions=compress MH 6.8.x viamail: used with application/octet-stream;
- type=tar. See also tar(1) and compress(1).
-
- --------------------------------
-
- 10.3) Internet Engineering Task Force (IETF) working groups
-
- The IETF working group on Privacy-Enhanced Mail (PEM) has developed
- extensions that permit confidentiality, authentication, and integrity
- to be provided in a manner backwards compatible with RFC 821 and
- RFC 822. Work is underway to align PEM and MIME which will provide
- real security to MIME e-mail.
-
- The IETF MIME working group is not actively considering significant
- changes to the specifications. However the WG still exists as a forum
- for MIME developers, as a home for interpretation questions, and to
- handle any problems or ambiguities that might arise in MIME.
-
- --
-
- 11) Developers' FAQs
- --------------------
-
- 11.1) How can I register a new MIME type?
-
- The procedures for registering new content types, character set
- values, access types, and conversions parameters with IANA (the
- Internet Assigned Numbers Authority) are documented in RFC 1590.
-
- --------------------------------
-
- 11.2) What's ESMTP, and how does it affect MIME?
-
- ESMTP (Extended Simple Mail Transfer Protocol) is a mechanism by which
- extensions to "traditional" (RFC 821) SMTP can be negotiated by client
- and server. The mechanism (RFC 1651) is open-ended; so far two
- extensions have been defined.
-
- Message size declaration (RFC 1653) offers a graceful way for servers
- to limit the size of message they are prepared to accept. (With SMTP,
- the only possibility is for the server to discard the message after it
- has been sent in its entirety. There is no way for the client to know
- that it was the size of the message that caused the problem.)
-
- When a message is returned to the user as being too large to deliver,
- one possible approach might be to fragment the message using the MIME
- Message/Partial mechanism, and resubmit it.
-
- Depending on the exact reason for the "too large" rejection, this may
- or may not be a good idea. For example, the limitation may reflect
- the recipient's disk quota, in which case the fragmented message will
- not be fully deliverable either.
-
- The possibility of fragmentation should, therefore, be left to the
- user's discretion (not performed automatically by the SMTP client).
-
- 8bit-MIMEtransport (RFC 1652) opens up the possibility of sending 8bit
- data in mail messages, without having to use base64, quoted-printable,
- or another encoding, and without the breakage that can result from
- sending 8bit data to an unsuspecting RFC 821 SMTP server. RFC 1428
- (Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME)
- discusses some of the implications of this.
-
- --------------------------------
-
- 11.3) Where can I get some sample MIME messages?
-
- ftp://thumper.bellcore.com/pub/nsb/samples/
-
- --------------------------------
-
- 11.4) Wouldn't MIME be better if it did <foo>?
-
- This question is asked for various values of <foo>. Perhaps the most
- common is "multilevel encodings": see the next question. There are
- a couple general points that apply to all <foo>.
-
- 1. Please remember that MIME is the result of a lot of work by a lot
- of persons, over a long time (look at the Acknowledgements section of
- RFC 1521). A great many ideas, probably including yours, were
- considered. In many cases, there were conflicting goals, such as
- simplicity and interoperability on the one hand, and power and
- flexibility on the other.
-
- 2. If you really think you've got an original idea which would improve
- MIME, the correct place to pursue it is not this newsgroup, but the
- working group mailing list (having first read the archives, to check
- that it really is new). Yes, this is going to be a lot more work than
- posting a news article.
-
- --------------------------------
-
- 11.5) So what about multilevel encodings?
-
- MIME uses a two-level encoding scheme. The original object (for
- example, a picture, or a text document) is encoded using a well
- defined mechanism appropriate to that object (perhaps GIF for the
- picture, and text/enriched for the document). Then a second encoding
- is used to ensure that the first encoding can be transmitted intact
- (probably base64 for the GIF, and quoted printable for the
- text/enriched document).
-
- Note that there is a very small number of the second encodings (five,
- but three of these are simply indications of what kind of data an
- unencoded body part contains), and it is not expected that there will
- be many more in the foreseeable future.
-
- The multilevel encodings idea is for a more generalized MIME-like
- encoding mechanism that could indicate many arbitrary transformations
- of the original object. For example,
-
- Content-Type: application/tar; conversions="encrypt,compress,uuencode"
-
- might indicate a UNIX tar file that had been encrypted, then
- compressed, then uuencoded. (This is a fictitious example of how MIME
- might have worked; it's not legal MIME. Don't worry if you've never
- heard of some of these transformations.)
-
- This may look like an attractive scheme at first, but it has a number
- of problems.
-
- 1. If you've been brought up on UNIX and command pipelines, the
- implementation of such a scheme seems trivial. Surely any half-decent
- machine can do something similar? Unfortunately, this turns out to be
- true only for a very restricted definition of "half-decent". In
- practice, it would be awfully difficult to implement this on a lot of
- systems. Probably even more systems would not allow new
- transformations to be just "slotted in", and would require
- recompilation or reshipping whenever a new one came along.
-
- 2. Each successive transformation reduces the size of the audience who
- can successfully decode the message. Every MIME mailer must be able
- to decode base64 and quoted-printable, so it's guaranteed that you can
- at least get back to the raw data. What if, in the above example, I
- have tar, decrypt, uudecode, but no uncompressor?
-
- 3. Such a scheme does not increase the scope of the framework defined
- by MIME. If uuencoded, compressed, encrypted tar files are useful
- things to sling around, it is entirely possible to define a new MIME
- type (presumably a subtype of application) to handle them.
-
- --------------------------------
-
- 11.6) Why doesn't MIME include a mechanism for compression?
-
- Compression is a difficult area. It was considered by the working
- group, but no consensus was reached. There is still work going on in
- this area: there may someday be a compressed-64 encoding.
-
- Most compression algorithms have one of more of these undesirable
- properties: they are covered by patent, they require the ability to
- treat the input as a stream of bits, they use a large data space. The
- chances of finding a truly interoperable compression algorithm are
- therefore rather slim.
-
- It is worth noting that most or all of the image and video subtypes
- (including GIF, JPEG, TIFF, and MPEG) define their own compression
- schemes.
-
- --
-
- 12) Acknowledgements
- --------------------
-
- Many persons have contributed to this document.
-
- They include:
-
- Alan Robiette, Alec Henderson, Axel Boldt, Carlyn Lowery, Chris
- Pepper, Christophe Wolfhugel, Christopher Davis, Craig Huckabee,
- Daniel Fandrich, Daniel Glazman, Dave Curry, Dave Lacey, David Barr,
- David Collier-Brown, David Miller, Douglas Boyce, Ed Anselmo, Ed
- Greshko, Edward Vielmetti, Erik van der Poel, Gisle Hannemyr, Harald
- Alvestrand, Ian Hoyle, James Ford, Jason Beyer, Jay Weber, Jerry Peek,
- Jerry Sweet, Joe Ilacqua, Joergen Haegg, John Gardiner Myers, John
- Martin, John R MacMillan, John Romine, Joyce Reynolds, Keith Moore,
- Larry Salomon Jr, Larry W. Virden, Lars-Gunnar Olsson, Luc
- Rooijakkers, Marc VanHeyningen, Mark Crispin, Mark Grand, Marshall
- Rose, Martin Wendel, Masanobu Umeda, Michael Parson, Michael Urban,
- Nathaniel Borenstein, Ned Freed, Niklas Agren, Olle Jarnefors, Pat
- Farrell, Paul Eggert, Piero Serini, Quentin Smart, Ran Atkinson, Ray
- Langford, Rich Ragan, Rick Troth, Ron Barak, Sascha Wildner, Steve
- Dorner, Steve Hole, Stuart Lynne, Susan Straub, Syd Weinstein, Tim
- Goodwin, Tim Kehres, Tommy Wallo, Yehavi Bourvine.
-
- If we've left your name off, please accept our apologies. Drop us a
- note and we'll include it for next time.
-
- Thanks also to the University of California, Irvine, Department of
- Information and Computer Science, Einar Stefferud, and Irvine Compiler
- Corp., for providing the resources for maintaining this FAQ; and to
- Jonathan Kamens, for coordinating the *.answers groups, and for his
- post_faq program which brought you this FAQ.
-
- --
- End of Part 3
- *************
- --
-
-